Administering
your SQL Azure projects is easy. Go ahead and click the project you
created in the Summary window. You're prompted to enter a username and
password. (You see how this information is used in a moment.) After you
enter your username and password, you're presented with the SQL Azure
Server Administration portal, shown in Figure 1.
The Server
Administration portal displays three categories of information that are
vital to administering, connecting to, and working with SQL Azure. You
see information about your server, including its name and location. You
also have two tabs: one showing your firewall settings and the other
listing your databases.
1. Server Information
The Server Information box is at the top of the Summary tab. Figure 1 shows that box in context, and Figure 2 focuses in so you can read the details.
The Server Information box displays the following:
Server Name.
The fully qualified domain name (FQDN) of your logical database
server—a physical machine name that resolves to an IP address at the
Microsoft data center. This is not
the database server name. When a connection is made to this IP address,
your connection is routed to the physical database server based on your
login name and the database (master, for example).
Administrator Username. The name you entered in the pop-up dialog when you clicked the project name in Figure 2.
Whenever you connect to SQL Azure, for example through SQL Server
Management Studio, this is the username you use, along with the
associated password.
Server Location.
The geo location where your Azure server resides. As of this writing,
there are seven locations: Anywhere Asia, Anywhere Europe, Anywhere US,
North Central US, North Europe, South Central US, and Southeast Asia.
Microsoft
recommends that when creating your logical servers, you should put them
in the same geo location. If you don't, you incur data charges. For
example, if you put your Windows Azure web application in the North
Central US location and your SQL Azure database in the South Central US
location, you incur data-transfer and other transactional charges. If
your application and database are located in the same geo location, you
don't incur these charges. Another reason to put your application and
database in the same geo location is performance. However, spreading
your services across geo locations helps with redundancy.
A quick note about the Drop
Server button in the Server Information box: dropping a SQL Azure
server deletes all databases associated with the server and removes the
server from your account. When you drop a server, you're informed that
dropping the server can't be undone and asked whether you want to
continue. If you choose to continue, no databases can be recovered, and
you must start the server-creation process all over again, including
creating a new administrator and selecting the location.
